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Remarks/Arguments 

A. Claims In The Case 

Claims 41-70 have been rejected. Claims 41-70 are pending in the case. Claims 41-45 
and 47-59 have been amended to correct typographical errors and/or for clarification. 

B. The Claims Are Directed to Statutory Sub ject Matter Pursuant To 35 U,S>C, § 101 

The Examiner rejected claims 41-70 under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. 

Claims 41, 47, 59, and the claims dependent thereon have been amended for clarification. 
Applicant respectfully requests the Examiner withdraw the rejection to claims 41-70. 

C. The Claims Are Not Obvious Over Johnson et aL in view of McKee et aL Pursuant 
To 35 U,S.C, § 103(a) 

The Examiner has rejected claims 41-70 as being unpatentable over U. S. Patent 
4,987,538 to Johnson et al. (hereinafter "Johnson") in view of U.S. Patent No. 6,272,482 to 
McKee et al. (hereinafter "McKee"). Applicant respectfully disagrees with the rejection. 

In order to reject a claim as obvious, the Examiner has the burden of establishing a prima 
facie case of obviousness. In re Warner et al, 379 F.2d 1011, 154 U.S.P.Q. 173, 177-178 
(C.C.P.A. 1967). To establish a prima facie obviousness of a claimed invention, all the claim 
limitations must be taught or suggested by the prior art. In re Royka, 490 F.2d 981, 180 U.S.P.Q. 
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580 (C.C.P.A. 1974), MPEP § 2143.03. 

Amended claim 41 is directed toward a computer system that includes, but is not limited 
to, the features of: 

a database comprising a plurality of business rule data elements; 

a translator program configured to read two or more of the business rule 
data elements from the database, and to combine at least two of the business rule 
data elements to form at one or more business rules; and 

a rules engine configured to assess a value of one or more insurance claims 
as a function of at least one of the formed business rules. 

The Examiner states, 

Johnson discloses a system a database comprising a plurality of business rule data 
elements; a translator program configured to read two or more business rule data 
elements from the database and to combine two or more business rule data 
elements to form at least one business rule. . . .McKee suggests a rules engine 
configured to assess a value of an insurance claim as a function of at least one 
business rule from by the translator program. 

Applicant respectfully submits that neither Johnson, nor McKee, alone, or in 
combination, appears to teach or suggest the combination of features of claim 41, including but 
not limited to, the feature of, "a translator program configured to read two or more of the 
business rule data elements from a database, and to combine at least two of the business rule data 
elements to form one or more business rules." 



Johnson appears to teach manually converting business rules into source code, selecting 
the business rule, then applying the business rule to a billing. Johnson states, 

administrative rules 10 are converted into rule codes 12 and stored in the memory 
of the computer 14. A software program enables the computer to select the 
appropriate rules and sequentially apply the rules to each specific billing 
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(Johnson, column 3, lines 8-12). 

A computer programmer, given the information contained herein, will readily 

produce the 'progranmiing generating step' Basically the source code is a 

refinement of the logic statements given as examples for the 'rules conversion 
step'. 

(Johnson, column 5, lines 38-44) 

Applicant submits that Johnson, like other prior art systems, appears to rely on computer 
progranmiers to create a database of software rules based on a plurality of "administrative rules." 
As stated in Applicant's specification, the use of a skilled computer progranmier suffers from 
disadvantages that are remedied by the method of Applicant's claims. For example. Applicant's 
specification states: 

There were several drawbacks with the prior art knowledge-based system. 
For example, the business rules used in the prior art often lacked flexibility. The 
business rules were often hard-coded in the insurance claim processing software. 
Every time there was a new business requirement, it was necessary to change the 
source code. In some cases, this inflexibility resulted in delaying the 
incorporation of the new business rules until the next system release date. Thus 
the insurance claim processing software was unable to adapt quickly to changing 
business conditions. This reduced the users' and therefore the insurance 
companies' flexibility to respond to changing business conditions in assessing 
bodily injury claims. 

Very often, the user may have special or unique requirement, which may 
need the standard business rules to be modified (i.e., customized) to meet a 
specific application. The hard-coding method used in the prior art would not 
easily permit the customization of the business rules in a cost and time effective 
manner. 

It is, therefore, desirable to develop a new system and method for 
extemalization of rules for assessing bodily injury general damages. It is desirable 
for the rules to be easily updateable based on external business conditions. It is 
also desirable for the rules to be customizable to meet specific user requirements. 
Thus, the new system and method for extemalization of rules should be of a 
flexible design, to meet user requirements. 
(Specification, page 2, lines 5-24) 
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McKee appears to teach or suggest management of rules and user changing the rules. 
McKee states, 

It is an object of the present invention to provide a method and system for 
managing business rules. . . 
(McKee, column 2, lines 49-50) 

an application program . . ..generally comprising the steps of defining a plurality of 
jurisdictions adapted to exert authority over a decision of the application program, 
creating at least one control point for the decision and mapping rules from the 
jurisdictions to the control point. 
(McKee, colunrn 2, lines 55-60). 

A 'jurisdiction' can represent a company, a legal entity (such as a state), a line of 
business (such a property insurance or automobile insurance), or even a team 
office, workgroup or department within a business. 
(McKee, colunm 3, lines 62-66). 

The business user must determine which rules to change... The business domain 
expert can be made aware of this by examining rules known to jurisdictions 
through the 'minimum AutoCancelNotification' control point 7a. This control 
point is one of possibly several control points used to in making the business 
decision 8 of when to cancel an insured's pohcy.... 
(McKee, colunm 4, line 64 through colunm 5, line 5). 

The present invention may be further understood with reference to the 
flow chart of FIG. 3. The process begins with execution of an application 
program (9), which interrogates a jurisdiction upon detecting a control point (10). 
The jurisdiction is interrogated to determine whether it desires to assert control 
over the business decision represented by the control point. The jurisdiction 
determines it interest by inspecting the object (11). If the jurisdiction determines 
that is has rules to apply (12), then the system requests those rules (13). The 
jurisdiction also alerts the system as to whether the jurisdiction is to assert 
exclusivity (14) and, if so, excludes lower priority jurisdictions from the decision 
process (15). If the jurisdiction does not assert exclusivity, then the system 
examines the priority of the relevant rule for that jurisdiction, in relation to other 
jurisdictions which have been interrogated fro the control point (16). If a higher 
priority rule applies, then any rule from the current jurisdiction is disregarded 
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(17) . This process is repeated for each jurisdiction affected by the control point 

(18) . After all relevant rules have been identified, program execution continues. 
(McKee, column 5, lines 32-51). 

Johnson in combination with McKee appears to teach conversion of rules into code, 
selection of rules, and management of rules. Johnson in combination with McKee does not 
appear to teach or suggest a translation program which is configured to read two or more of the 
business rule data elements from a database, and to combine at least two of the business rule data 
elements to form one or more business rules. For example, with regard to the translation 
program, the Specification of the present application states: 

Other types of tables stored in the database 40, in one embodiment, may 
include a LineText table as shown by way of example in Figure 3c and a Template 
table as shown by way of example in Figure 3b. The LineText table may store 
lines or other elements of text which may be used to generate the rules. The 
Template table may include information which may be used by the application 
program to read each row of data from the rules data table and transform, create or 
generate the rules data into a rule. In one embodiment, every rule style may have 
an entry in the Template table. The location to store the transformed rule, the 
name of the rules data table, the name of the rule style, an identifier for the line 
text, etc. may also be included in the Template table, in one embodiment. 
(Specification, p. 15, hnes 4-13). 

In step 140, data entries in each column of the rules data table are used to 
transform, create, or construct the rules. Entries for colunms like rules style and 
rules name in the rules data table may be used as a key to find a matching record 
in the Template table. Other data stored in the columns of the rules data may be 
used to build the rule premise and/or the resulting one or more rules action. 
(Specification, p. 15, lines 22-26). 

For at least the reasons discussed above, Applicant respectfully submits that Johnson in 
combination with McKee does not teach the combination of the features of independent claim 41 
including, but not limited to, the feature of, "a translator program configured to read two or more 
of the business rule data elements from the database, and to combine at least two of the business 
rule data elements to form one or more business rules." As such. Applicant submits independent 
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claim 41 and claims dependent thereon (i.e., claims 42-46) are patentable over the cited art. 

Amended claim 43 states in part, "wherein the business rule data elements are stored in 
tabular format in the database." The Examiner states, "Johnson discloses the system wherein the 
plurality of business rule data elements are stored in a tabular format in the database." Applicant 
respectfully disagrees. Applicant submits that Johnson appears to teach use of listings of 
predefined administrative rules. The administrative rules do not appear to be stored in tabular 
format in the database that includes the business rules. For example, Johnson states. 

Examples of how the above five steps are actually implemented is provided 
below. These examples are based on the administrative rules that govern Workers' 
Compensation Insurance benefits for the State of Oregon. (OAR=Oregon 
Administrative Rules) 

(a) The rules conversion step. Examples of three OAR sections are listed below 
followed by the computer code. 

(Johnson, column 4, lines 42-49). 

Applicant submits that Johnson does not appear to teach or suggest the features of the 
claim. Applicant further submits that features of claim 43, in combination with the features of 
claim 41, are patentable over the Johnson in view of McKee. 

Amended independent claims 47 and 59 include the features of: 

providing a plurality or business rule data elements in a memory of the 
computer system; 

combining two or more of the business rule data elements to form one or 
more business rules for processing one or more insurance claims; and 

providing at least one of the formed business rules to a rules engine, 
wherein the formed business rule is executable by the rules engine to process at 
least one of the insurance claims. 

For at least the reasons discussed above. Applicant respectfully submits that claims 47, 
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59, and the claims dependent thereon (i.e., claims 48-58 and 60-70, respectively) are patentable 
over the Johnson in view of McKee. 

Amended claim 55 states in part, "modify one or more of the business rule data elements 
in the memory and combining at least two of the business rule data elements, including at least 
one of the modified business rule data elements, to form one or more modified business rules." 

Claim 56 states in part, "modifying one or more of the business rule data elements as a 
function of at least one business requirement of an insurance organization." 

Claim 57 states in part, "modifying at least one of the business rules in response to 
modifying at least one of the business rule data elements." 

Claim 58 states in part, "forming at least one new business rule in response to modifying 
at least one of the business rule data elements." 

The Examiner states, 

per claim 55, Johnson discloses.... modifying at least one business rule data element in 
the memory... 

per claim 56, Johnson discloses... modifying at least one business rule data element as 
function of business requirements of an insurance organization." 

per claim 57 Johnson discloses.... modifying at least one business rule in response 
to modifying at least one business rule data element. . . 

per claim 58 Johnson discloses.... forming at least one new business rule in 
response to modifying at least one business rule data element (Col. 2, lines 56-68 
to Col. 3, line 25). 
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Applicant submits that Johnson does not appear to teach or suggest the features of the 
claims including, but not limited to, the feature of, "modifying one or more of the business rule 
data elements in the memory." Applicant submits that Johnson appears to teach a listing of 
qualifiers and modifiers. The qualifiers and modifiers are applied to a business rule to determine 
a pay out. Johnson states. 

The administrative rules include a listing of all of the different types of treatment 
applicable to injury claims and the allowed payments form the treatments. 
Numerous qualifiers or modifiers are part of this 'listing'. Thus, a permitted 
payment may be increased if two doctors are in attendance, but payment to the 
second doctor may include a modifying factor that reduces payment to him... The 
computer must be able to identify the claim and the provider of the treatment. It 
also must be able to identify the treatment provided and determine any factor 
which will effectively modify the basic pay out, e.g., whether one or two 
physicians were in attendance, etc. 
(Johnson, column 2, line 60 through colunm 3, line 25). 

Applicant submits that Johnson does not appear to teach or suggest the combination of 
the features of the claims including, but not limited to, the feature of, "modifying one or more of 
the business rule data elements in the memory." As such. Applicant submits that claims 55-58 
are patentable over Johnson. Applicant further submits that the features of claims 55-58, in 
combination with the features of independent claim 47, are patentable over Johnson in view of 
McKee. 



Amended claim 60 states in part, "wherein the program instructions are further 
computer-executable to implement processing at least one of the insurance claims by 
executing at least one of the formed business rules in the rules engine." The Examiner 
states, "Johnson discloses the carrier medium. . . .to implement processing at least one 
insurance claim by executing at least one formed business rule in the rules engine." 
Applicant respectfully disagrees. 
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Applicant submits that Johnson does not teach the feature of the claim including 
but not limited to, the feature of "a rules engine." The Examiner concurs. The Examiner 
states, "Johnson does not explicitly disclose providing at least one formed business rule 
to a rules engine, wherein at least one formed business rule is executable by the rules 
engine to process at least one insurance claim." As such, Applicant submits that claim 60 
is patentable over Johnson. Applicant further submits that the features of claim 60 in 
combination with the features of independent claim 59 are patentable over Johnson in 
view of McKee. 

D. Response to Arguments 

In the "Response to Arguments" portion of the Office Action, the Examiner states that 
features newly added in the 1 1/10/03 amendment have been fully addressed by the Examiner as 
either being fully disclosed or obvious in the view of collective teachings of Johnson and McKee. 
Applicant respectfully disagrees. For at least the reasons stated above. Applicant submits that 
Johnson, alone, or in combination with McKee does not teach or suggest the features of the 
claims. As such, Applicant submits that claims 41-70 are patentable over Johnson in view of 
McKee. 

E. Prior Art Made of Record 

The Examiner states that prior art of, U.S. Patent Nos. 6,098,070 to Maxwell (hereinafter 
"Maxwell"), 6,272,471 to Segal (hereinafter, "Segal"), and 5,504,674 to Chen et al. (hereinafter 
"Chen"), has been made of record but not relied upon. Applicant submits that Maxwell, Segal, 
or Chen alone, or in combination, do not teach or suggest the combination of the features of 
claims 41-70. 
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F. Further Remarks 

Favorable reconsideration is respectfully requested. 

Applicant respectfully requests a one month extension of time to respond to the Office 
Action dated January 30, 2004. A fee authorization form in the amount of $110.00 is enclosed 
for the extension of time fee. If any further extension of time is required, Applicant hereby 
requests the appropriate extension of time. If any fees are inadvertently omitted or if any 
additional fees are required, please charge those fees to Meyertons, Hood, Kivlin, Kowert & 
Goetzel, P.C. Deposit Account Number 50-1505/5053-28000/EBM. 



MEYERTONS, HOOD, KIVLIN, KOWERT & GOETZEL, P.C. 

P.O. BOX 398 

AUSTIN, TX 78767-0398 

(512) 853-8800 (voice) 

(512) 853-8801 (facsimile) 



Respectfully submitted. 




Mark R. DeLuca 
Reg. No. 44,649 
Patent Agent for Applicant 



Date: 
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